This also ties into linux-surface/linux-surface#2094 I believe.

Thanks!

I think this would also resolve linux-surface/linux-surface#2076 (due to just the version bump)

I am not a maintainer, but I notice that you replaced a lot of the build process, and bumped unrelated action versions. Was this explicitly required? My experience is that maintainers are less likely to review PRs that don't look very clean, and that make lots of extraneous changes.

Is there a more minimal version of this PR that you'd like to see upstreamed? I'm curious if you could easily add fedora-44 without replacing fedora-42 in the build scripts (which I presume would remove support for federo-42)?

Regardless, thanks for making the PR!

Hi patcon, many thanks, hope its useful.

I made the PR providing the maintainers with the option to edit PR before merge so that should provide them with one means.
More than that though, I intentionally split the commits in the way that I did for the reasons you highlight, and I'm counting on it being fairly trivial for the maintainers to cherry-pick stage which commits want to keep into perhaps their own PR.

In particular I bumped the action versions as I can see that equivalent updates had already been merged into the other CI workflows, so presumably it needed doing. I see it as in fact hard to defend adding new code for new steps calling on sun-setting action versions. At which point not updating the other action versions I saw as a messy job half done that would leave a single single unit of code in an (almost invalid) Frankenstein's monster mess of mixed states. I was betting that actually made the PR easier to accept as ready.
It could be that there is an argument for not 'removing' the fedora 42 workflows, but as I see it it could only be wrong to build Fedora 42 for 2.18, since all Fedora packages simply end at the last state when it went out of support. Anyone choosing to remain on Fedora 42, is presumably choosing to 'freeze' and an automated dnf pull of a new version might cause a break they are entitled not to expect to have to deal with. Furthermore, there are already releases in Repo for the earlier libwacom version.
EDIT: I should also add that this was the reason the commit removing 41 and 42 comes as the last commit affecting release.yml dropping it should not cause conflicts for other cherry-picks.

If when a maintainer looks at the PR, any feedback on how I can better help in the future, if for example its in part or exactly as you highlight, would be greatly appreciated.

If there was a test branch to do the PR against I might have done exactly as you say, but I saw the sum of all these commits as being necessary in order for them to be commendable to master production. I took a guess.

Anyway, as I say my overriding reasoning though is just that I'm assuming it will be easy for the maintainers to cherry pick to exclude any commits they don't want.